IBIS Macromodel Task Group Meeting date: 13 June 2017 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan * Ken Willis eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield SiSoft: Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - Bob noted that Ambrish's new proposal (see ARs below) should be a new item on the agenda. Arpad agreed and said this was an oversight. ------------- Review of ARs: - Ambrish to prepare a BIRD draft extending the warning about optimization in Init() to the redriver flow section. - Done. Emailed to ATM. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Mike L.: Motion to approve the minutes. - Ambrish: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: BIRD 158.6: - Arpad: Do we have an update on this? - Radek: I've been away, there has been no recent activity. - Arpad: What will this revision address? File naming rules? - Radek: There have been some email discussions that it will address, including issues you raised. - Clarification of issues related to whether package models from the IBIS file are used or not. - Bob: We want to be clear that the Ts4file can contain a file reference, not just a file name. We want to use language related to BIRDs 186 and 189. - Radek: Yes, we need to expand that to a path beyond the current directory. - Arpad: When will we have a new version? - Radek: Let's see the status of BIRD 186. It probably shouldn't be done ahead of BIRD 186. - We can probably have a new version to review in a couple of weeks. - Bob: The file reference part of BIRD 186 is very close to finalized. Ambrish's BIRD draft: - Ambrish: [sharing the BIRD draft] - As I was reading through the repeater section, I thought it was clear that the regular single-channel flow should be followed for each section of the channel, once the redriver stuff has been taken into account. (so the existing warning, on pg. 178 of IBIS 6.1, about optimizing in Init() should already apply). - However, I wanted to make sure it's very clear to the model maker or redriver user that this warning is extended to the redriver flow section. - [Ambrish's proposal inserted the following warning paragraph, derived from that on pg. 178, into the repeater time domain flow after step 6.] Note: The Rx executable model file writer for the redriver and downstream channels should keep in mind that it is not guaranteed that the impulse response that is presented to the Rx AMI_Init function will always include the effects of the Tx filter or any upstream equalization. Therefore the Rx AMI_Init function may not be able to perform accurate optimization under all circumstances. For this reason, the parameters of the Rx AMI_Init function should always default to valid values or have a mechanism to accept user-defined coefficients and allow the user to turn off any automatic optimization routines to ensure successful simulations. - Arpad: To recap from last week's meeting: - Over the last couple months' discussions, it has become apparent that BIRD 166 would have some technical issues. - It doesn't fix every case. - It actually makes some cases worse, as demonstrated by Fangyi. - Can we come up with a version of BIRD 166 that satisfies everyone? - Walter then proposed the idea to only document the working cases (all Init Only, all GetWave Only, all Dual) - I think this is a mild form of saying we don't support anything else. - So the question is then, does BIRD 166 solve anything? - Last week we discussed the possibility of rejecting BIRD 166 and using this clarifying statement (Ambrish's proposal) instead. - In email discussions Walter said we should approve BIRD 166, but I'm not sure which version he was referring to. - It's decision time as far as I'm concerned. - Mike L.: Hopefully Walter can be back next week. - Bob: I thought Walter suggested passing BIRD 166, and including Ambrish's comments, and including Walter's additional statements about proxy Init() or GetWave() being problematic? - I think we could also just accept Ambrish's BIRD and reject BIRD 166. - If we limit this to Ambrish's BIRD is that satisfactory? - Arpad: I thought accepting Ambrish's BIRD would remove the need for BIRD 166. - Fangyi: Yes, that's actually Ambrish's purpose. - Ambrish: Yes. Saying BIRD 166 solves the redriver flow problem is not true. - It changes the flow and that has repercussions everywhere. - That basic optimization problem in Init() exists in the single-channel case as well, and there's nothing really special about the redriver case. - I don't believe it's a problem at all because we don't see many models with optimization in Init(). The warning message is sufficient. - Fangyi: I agree, the problem already existed in the single-channel flow. - It's just more prominent in the redriver case. - That's why my proposal is trying to solve the normal flow, not just the redriver flow. - Bob: Just want to note that BIRD 166 is currently tabled. - Does Keysight support Ambrish's BIRD? - Fangyi: Yes, this is just a clarification of the redriver section. - Bob: So it doesn't solve everything, but it doesn't break anything? - If Fangyi's proposal is adopted in the future, we can adjust this text if necessary? - Fangyi: Yes. - Arpad: Later on, if we adopt Fangyi's proposal, then we can remove this new warning and the corresponding version in the single-channel flow, right? - Fangyi: We would probably rephrase this clarification. - I also agree with Arpad's observation that documenting certain scenarios is just another way to disallow other combinations. - Bob: It doesn't make it illegal, it just cautions that it's at your own risk. - Fangyi: Also (referring back to Arpad's "AMI Flow Problem Summary" from the May 30th meeting), you had a bullet point in your presentation about crosstalk. - There are indeed problems with crosstalk. - Arpad: Thanks for confirming. We added "?" to the crosstalk items during the meeting when Walter said there was no problem. - Fangyi: One is implementation. - Using the "self IR" terminology from Arpad's presentation, the fact that BIRD 166 deprives the EDA tool of the self IR is forcing the EDA tool to to present the IR of every possible aggressor path in the Impulse Matrix at once. - You have to figure out all the possible paths from point A to point B and include them all in the crosstalk IR portion of the Impulse Matrix. - In a cascaded redriver simulation with crosstalk, the combinations can explode exponentially and that matrix size explodes. - Mike L.: Is there a better approach? - Fangyi: You allow the self IR, and then it's up to the EDA tool to handle all the combinations. - You only have to put the individual channel's crosstalk IRs in the matrix. - That's also what Ambrish is concerned about, from a slightly different point of view. He's worried about the signal passing all the way through all the channels even if you have 100 redrivers. You'd need to get a cumulative impulse matrix that has everything. - There's another problem that is more minor. - Each Init() can only apply its equalization filter to the IR once. - Imagine if you have a loop where the signal goes through the same device twice. Then you're doomed if you don't have the self IR. If you force these cumulative IRs then you can't represent a loop. - Arpad: It's becoming clear that the only way to handle crosstalk and some of these other combinations we are facing is to have a solution with both the self and cumulative IRs. - Fangyi: Yes, we must have both self and cumulative IRs. - Discussion of the text of Ambrish's BIRD Draft: Mike L. asked that Ambrish create the BIRD draft using the latest template (v 1.3). Ambrish agreed. Radek suggested that it wasn't entirely clear which Rx the text was referring to, and he suggested using the Rx2 terminology to make it clearer to a new reader. Ambrish said it was general and applied to all the Rx models. Radek and Fangyi suggested something like "in particular Rx2". Curtis said he understood that Ambrish's text was meant to be general and apply to Rx1 and Rx2. But he noted that in a redriver simulation, given the current flow, the Rx2 Init() function "will not" see any upstream effects. Curtis asked if we should somehow highlight this fact, because the proposed text "it is not guaranteed that the impulse...will always contain..." could be misleading. For an Rx2 in a redriver, the IR passed to Init() is guaranteed not to contain the upstream effects (given the current redriver flow). Ambrish said the goal had been to keep the comment general and that the flow defined in the spec was not necessarily mandatory. The warning was a general reminder. Curtis said he was okay with this, and imagined the less specific language would allow for tools that might follow a BIRD 166 approach (and convolve in the output of Rx1 Init() prior to calling Rx2 Init()) in some particular scenarios. Arpad, however, said the point Curtis had raised was important, and the text should be strengthened to reflect the defined flow and the fact that the Rx2 Init() would not see any upstream effects. The group worked on modifying the text in this direction, and arrived at: Note: The Rx2 executable model file writer for the downstream channels with Redrivers should keep in mind that the impulse response that is presented to the Rx AMI_Init function does not include the effects of the upstream equalization. Therefore, the Rx AMI_Init function will not be able to perform accurate optimization in the absence of the upstream channel characteristics and/or equalization effects. For this reason, the parameters of the Rx AMI_Init function should always default to valid values or have a mechanism to accept user-defined coefficients and allow the user to turn off any automatic optimization routines to ensure successful simulations. - Arpad: Ambrish, could you take the AR to submit this proposal, with the modified language, to the Open Forum and the ATM for posting? - Ambrish: Yes. Agenda Item #9: New BIRDs from Editorial Task Group - Arpad: This item has been around for a long time. - Any updates? Should I remove it? - Bob: Keep it on the agenda. - I have no updates. Radek and I have set it aside for now. - Radek: Motion to adjourn. - Ambrish: Second. - Arpad: Thank you all for joining. AR: Ambrish submit his proposal, with the modified language, to the Open Forum as BIRD 190 and to the ATM for posting. ------------- Next meeting: 20 June 2017 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives